Applications for using mass estimations for vehicles

ABSTRACT

Various applications for use of mass estimations of a vehicle, including to control operation of the vehicle, sharing the mass estimation with other vehicles and/or a Network Operations Center (NOC), organizing vehicles operating in a platoon and/or partially controlling the operation of one or more vehicles operating in a platoon based on the relative mass estimations between the platooning vehicles. When vehicles are operating in a platoon, the relative mass between a lead and a following vehicle may be used to scale torque and/or brake commands generated by the lead vehicle and sent to the following vehicle.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a Continuation of U.S. application Ser. No.15/988,905, filed May 24, 2018, which is a Continuation of U.S.application Ser. No. 15/908,677, filed Feb. 28, 2018, which is aContinuation-in-Part of International Application No. PCT/US17/047771,filed Aug. 21, 2017, which claims priority to U.S. ProvisionalApplication No. 62/377,970, filed Aug. 22, 2016.

The present application is also a Continuation-in-Part of U.S.application Ser. No. 15/607,316, filed May 26, 2017, which is aContinuation of U.S. application Ser. No. 14/292,583, filed May 30, 2014(now U.S. Pat. No. 9,655,102), which is a Divisional of U.S. applicationSer. No. 13/542,622 (now U.S. Pat. No. 8,744,666) and Ser. No.13/542,627 (now U.S. Pat. No. 9,582,006), both filed Jul. 5, 2012 andboth claiming the benefit of U.S. Provisional Application No.61/505,076, filed Jul. 6, 2011.

The present application is further a Continuation-in-Part of U.S.application Ser. No. 15/589,124, filed May 8, 2017, which is aContinuation of U.S. application Ser. No. 14/855,044, filed Sep. 15,2015 (now U.S. Pat. No. 9,645,579), which is a 371 National StageApplication of PCT/US2014/030770, filed Mar. 17, 2014, which claims thebenefit U.S. Provisional Application No. 61/792,304, filed Mar. 15,2013. The Ser. No. 14/292,583 application is further a Divisional ofU.S. application Ser. No. 13/542,622 (now U.S. Pat. No. 8,744,666) andSer. No. 13/542,627 (now U.S. Pat. No. 9,582,006), both of which claimpriority to U.S. Provisional Application No. 61/505,076, filed Jul. 6,2011.

All of the above listed applications are each incorporated herein byreference in their entirety for all purposes.

FIELD OF THE INVENTION

The present application relates generally to applications for use ofmass estimations of a vehicle, and more specifically, using a massestimation of a vehicle to control operation of the vehicle, sharing themass estimation with other vehicles and/or a Network Operations Center(NOC), organizing vehicles operating in a platoon or other arrangementof vehicles on the road and/or partially controlling the operation ofone or more vehicles operating in a platoon based on the relative massestimations between the platooning vehicles.

BACKGROUND

The mass estimation for a vehicle is known. For more details on massestimation for vehicles, see Bae et al., “Road Grade and VehicleParameter Estimation for Longitudinal Control Using GPS”, 2001 IEEEIntelligent Transportation Systems Conference Proceedings, Oakland,Calif., Aug. 25-29, 2001 and Holm, “Vehicle Mass and Road GradeEstimation Using Kalman Filter”, MSc Thesis, Department of ElectricalEngineering, Sweden, August 2011, both publications incorporated hereinby reference for all purposes.

While algorithms for estimating the mass of a vehicle are known, theapplication or use of such information is limited. With certainvehicles, mass estimation is used in the control of onboard AutomatedBraking Systems (ABS). Other than for braking control, however, theApplicant is not aware of other uses or applications for mass estimationinformation, either onboard or sharing with other vehicles or datacenters.

SUMMARY

The present application is directed toward using the mass estimation ofa vehicle for a number of applications.

In one application, the mass of a vehicle can be used as part of variousmethods to control the operation and system(s) on the vehicle itself(e.g., throttle, braking, steering, etc.).

In yet other embodiments, the use of vehicle mass estimations has anumber of applications in the context of platooning. Such applicationsinclude organizing vehicles in general, arranging for vehicles tooperate in a platoon using the relative estimated mass of each of thevehicles to select the lead and the following vehicles(s), scalingcommands sent from the lead vehicle to the following vehicles(s) basedon the relative mass of the vehicles operating in the platoon, andpossibly using the mass estimation of a vehicle to control operations onthe vehicle

In yet other embodiments, mass estimations, or sensor data used tocalculate mass estimations, can be transmitted to a data processingcenter, such as a Network Operations Center (NOC), which may remotelycoordinate the platooning of vehicles. For instance, by coordinating aplatoon and communicating the mass of the two (or more) vehicles priorto engagement, the vehicles can immediately assume their proper platoonposition (e.g., either the lead vehicle or following vehicle(s)) attheir point of contact. In yet other embodiments, a reset function isused for a data processing pipeline used for calculating a massestimation of a vehicle. In one instance, a primary mass estimation isconducted over a long horizon period of time. In parallel, a second massestimation is conducted over a short horizon period of time. When thetwo mass estimates differ by more than a threshold amount, it is assumedthe primary mass calculation has been compromised. As a result, theprimary mass calculation is reset and started anew with fresh sensordata. In another embodiment, the reset function can be triggered base on(a) a vehicle coming to a stop for more than a threshold period of time,(b) when the vehicle is traveling below a threshold speed or (c) basedon a GPS position of the vehicle. In various embodiments, the resetfunction may be triggered based on any one of (a) through (c) or anycombination of (a), (b) and/or (c).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention and the advantages thereof, may best be understood byreference to the following description taken in conjunction with theaccompanying drawings in which:

The invention and the advantages thereof, may best be understood byreference to the following description taken in conjunction with theaccompanying drawings in which:

FIG. 1 is a block diagram of a controller architecture suitable for usein an automated or partially automated vehicle control system thatsupports platooning.

FIG. 2 is a block diagram of a representative platoon controllerarchitecture suitable for use in the automated or partially automatedvehicle control system of FIG. 1.

FIG. 3 is a block diagram of a gap controller in accordance with oneembodiment.

FIGS. 4A-4C are a series of diagrams illustrating different controlstates used by a gap regulator in accordance with one embodiment duringdifferent operational states.

FIG. 5 is a state space diagram illustrating a sliding mode controlscheme.

FIG. 6 is a specific ASIL compliant controller hardware architecturesuitable for use in an automated or partially automated vehicle controlsystem that supports platooning.

FIG. 7 illustrates components of a gateway in accordance with oneembodiment.

FIG. 8 is a diagram showing how mass estimation of a vehicle is modeled.

FIG. 9 is diagram illustrating how multiple mass estimation samplepoints are plotted and averaged over time to arrive at a mass estimationfor a vehicle.

FIG. 10 is a diagram illustrating various possibilities for reporting amass estimation of a vehicle in accordance to different non-exclusiveembodiments of the present application

FIG. 11 is a flow diagram showing steps implemented by a NetworkOperations Center (NOC) using mass estimation data received frommultiple vehicles for coordinating and arranging the order of theplatooning vehicles.

FIG. 12 is a flow diagram showing steps how a following vehicle scalesaction commands received from a lead vehicle in the platoon based onrelative mass estimations between the two vehicles.

FIG. 13 is a diagram illustrating how a vehicle may use an estimation ofits mass to control operation and systems on the vehicle.

FIG. 14 illustrates a reset function used in cooperation with a dataprocessing pipeline used for determining a mass estimation for avehicle.

FIG. 15 is a flow chart of steps for executing a primary and a secondarymass estimation algorithm.

FIG. 16 is a flow diagram for resetting a mass estimation for a vehiclebased on the vehicle stops, speed and/or location.

DETAILED DESCRIPTION

The present invention will now be described in detail with reference toseveral embodiments thereof as illustrated in the accompanying drawings.In the following description, numerous specific details are set forth inorder to provide a thorough understanding of embodiments of the presentinvention, including the description of a plurality of different aspectsof the invention, including, in some case, one or more alternatives. Itwill be apparent to those skilled in the art that the invention can bepractice without implementing all of the features disclosed herein.

Platooning

The Applicant has proposed various vehicle platooning systems in which asecond, and potentially additional, vehicle(s) is/are automatically, orsemi-automatically controlled to closely follow a lead vehicle in a safemanner By way of example, U.S. application Ser. Nos. 15/605,456,15/607,902; 13/542,622 and 13/542,627; U.S. Provisional Application Nos.62/377,970 and 62/343,819; and PCT Application Nos. PCT/US2014/030770,PCT/US2016/049143 and PCT/US2016/060167 describe various vehicleplatooning systems in which a trailing vehicle is at least partiallyautomatically controlled to closely follow a designated lead vehicle.Each of these earlier applications is incorporated herein by reference.

One of the goals of platooning is typically to maintain a desiredlongitudinal distance or time headway between the platooning vehicles,which is frequently referred to herein as the “desired gap”. That is, itis desirable for the trailing vehicle (e.g., a trailing truck) tomaintain a designated gap relative to a specific vehicle (e.g., a leadtruck). The vehicles involved in a platoon will typically havesophisticated control systems suitable for initiating a platoon,maintaining the gap under a wide variety of different drivingconditions, and gracefully dissolving the platoon as appropriate.

The architecture and design of control systems suitable for implementingvehicle platooning may vary widely. The specific controller design canvary based on the level of automation contemplated for the controller,as well as the nature of and equipment available on the host vehiclesparticipating in the platoon. By way of example, FIG. 1 diagrammaticallyillustrates a vehicle control architecture that is suitable for use withplatooning tractor-trailer trucks. The specific controller illustratedis primarily designed for use in conjunction with a platooning system inwhich both vehicles include an active driver. The driver of the leadvehicle being fully responsible for control of the front vehicle. The adriver of the trailing vehicle is responsible for steering the trailingvehicle, but the platoon controller 110 is primarily responsible forcontrolling the engine torque of the trailing vehicles and brakingrequests during active platooning. However, it should be appreciatedthat generally similar control schemes can be used in systems whichcontemplate more automated control of one or both of the platoonpartners.

In the illustrated embodiment illustrated in FIG. 1, a platooncontroller 110, receives inputs from a number of sensors 130 on thetractor and/or one or more trailers or other connected units, and anumber of actuators and actuator controllers 150 arranged to controloperation of the tractor's powertrain and other vehicle systems. Anactuator interface 160 may be provided to facilitate communicationsbetween the platoon controller 110 and the actuator controllers 150.

The platoon controller 110 also interacts with an inter-vehiclecommunications controller 170 which orchestrates communications with theplatoon partner and a Network Operations Center (NOC) communicationscontroller 180 that orchestrates communications with a NOC. The vehiclealso preferably has selected configuration files 190 that include knowninformation about the vehicle.

Some of the functional components of the platoon controller 110 includegap controller 112, a variety of estimators 114, one or more partnervehicle trackers 116 and various monitors 118. In many applications, theplatoon controller 110 will include a variety of other components 119 aswell. Exemplary embodiments of the platoon controller 110 and gapcontroller 112 are described in more detail below with reference toFIGS. 2 and 3.

Some of the sensors utilized by the platoon controller 110 may includeGNSS (GPS) unit 131, wheel speed sensors 132, inertial measurementdevices 134, radar unit 137, LIDAR unit 138, cameras 139, acceleratorpedal position sensor 141, steering wheel position sensor 142, brakepedal position sensor 143, and various accelerometers 144. Of course,not all of these sensors will be available on all vehicles involved in aplatoon and not all of these sensors are required in any particularembodiment. A variety of other sensor 149 (now existing or laterdeveloped or commercially deployed) may be additionally or alternativelybe utilized by the platoon controller in other embodiments. In theprimary embodiments described herein, GPS position data is used.However, GPS is just one of the currently available global navigationsatellite systems (GNSS). Therefore, it should be appreciated that datafrom any other GNSS system or from other suitable position sensingsystems may be used in place of, or in addition to, the GPS system.

Many (but not all) of the described sensors, including wheel speedsensors, 132, radar unit 137, accelerator pedal position sensor 141,steering wheel position sensor 142, brake pedal position sensor 143, andaccelerometer 144 are relatively standard equipment on newer trucks(tractors) used to pull semi-trailers. However, others, such as the GNSSunit 131 and LIDAR unit 138 (if used) are not currently standardequipment on such tractors or may not be present on a particular vehicleand may be installed as needed or desired to help support platooning.

Some of the vehicle actuators controllers 150 that the platooncontroller may direct at least in part include engine torque controller152 (which is often part of the integrated functionality of an enginecontrol unit (ECU) or powertrain control module (PCM)), transmissioncontroller 154, brake controller 156, steering controller 157 (whenautomated steering is provided); and clutch controller 158. Of course,not all of these actuator controllers will be available or are requiredin any particular embodiment and it may be desirable to interface with avariety of other vehicle actuator controllers 159 that may be availableon the controlled vehicle as well. Therefore, it should be appreciatedthat the specific actuator controllers 150 directed or otherwiseutilized by the platoon controller on any particular controlled vehiclemay vary widely. Further, the capabilities of any particular actuatorcontroller (e.g. engine torque controller 152), as well as its interface(e.g., the nature and format of the commands, instructions, requests andmessages it can handle or generate) will often vary with the make andmodel of that particular actuator controller. Therefore, an actuatorinterface 160 is preferably provided to translate requests, commands,messages and instructions from the platoon controller 110 into formatsthat are appropriate for the specific actuator controller hardware andsoftware utilized on the controlled vehicle. The actuator interface 160also provides a mechanism for communicating/translating messages,commands, instructions and requests received from the various actuatorcontrollers back to the platoon controller 110. Typically an appropriateactuator interface would be provided to interact with each of thespecific vehicle controllers utilized. In various embodiments, this mayinclude one or more of an engine torque interface 161, a brake interface162, a transmission interface 164, a retarder interface 165 (if aseparate retarder controller is used), a steering interface 167, and/orany other appropriate controller interface 169.

Large trucks and other heavy vehicles frequently have multiple systemsfor “braking” the truck. These include the traditional brake systemassemblies mounted in the wheels of the vehicle—which are often referredto in the industry as the “foundation brakes.” Most large trucks/heavyvehicles also have a mechanism referred to as a “retarder” that is usedto augment the foundation brakes and serve as an alternative mechanismfor slowing the vehicle or to help prevent the vehicle from acceleratingdown a hill. Often, the retarder will be controlled by the engine torquecontroller 152 and in such embodiments, the retarder can be controlledby sending appropriate torque commands (which may be negative) to theengine torque controller 152. In other embodiments a separate retardercontroller (not shown) may be accessible to, and therefore directed by,platoon controller 110 through an appropriate retarder interface 165. Instill other embodiments, the platoon controller 110 may separatelydetermine a retard command that it sends to the actuator interface 160.In such embodiments the actuator interface will interpret the retardcommand and pass on appropriate retardation control commands to the ECUor other appropriate vehicle controller.

The communications between vehicles may be directed over any suitablechannel and may be coordinated by inter-vehicle communicationscontroller 170. By way of example, the Dedicated Short RangeCommunications (DSRC) protocol (e.g. the IEEE 802.11p protocol), whichis a two-way short to medium range wireless communications technologythat has been developed for vehicle to vehicle communications, workswell. Of course other communications protocols and channels may be usedin addition to or in place of a DSRC link. For example, the intervehicle communications may additionally or alternatively be transmittedover a cellular communications channel such as 4G LTE Direct, 5G, aCitizen's Band (CB) Radio channel, one or more General Mobile RadioService (GMRS) bands, and one or more Family Radio Service (FRS) bandsor any other now existing or later developed communications channelsusing any suitable communication protocol.

In various embodiments, the transmitted information may include thecurrent commands generated by the platoon controller 110 such asrequested/commanded engine torque 280, requested/commanded brakingdeceleration 282. They may also include steering commands, gearcommands, etc. when those aspects are controlled by platoon controller110. Corresponding information is received from the partner vehicle,regardless of whether those commands are generated by a platooncontroller or other suitable controller on the partner vehicle (e.g., anadaptive cruise control system (ACC) or a collision mitigation system(CMS)), or through other or more traditional mechanisms—as for example,in response to driver inputs (e.g., accelerator pedal position, brakeposition, steering wheel position, etc.).

In many embodiments, much or all of the tractor sensor informationprovided to platoon controller 110 is also transmitted to the platoonpartner and corresponding information is received from the platoonpartner so that the platoon controllers 110 on each vehicle can developan accurate model of what the partner vehicle is doing. The same is truefor any other relevant information that is provided to the platooncontroller, including any vehicle configuration information 190 that isrelevant to the platoon controller. It should be appreciated that thespecific information transmitted may vary widely based on therequirements of the platoon controllers 110, the sensors and actuatorsavailable on the respective vehicles, and the specific knowledge thateach vehicle may have about itself.

The information transmitted between vehicles may also includeinformation about intended future actions. For example, if the leadvehicle knows it approaching a hill, it may expect to increase itstorque request (or decrease its torque request in the context of adownhill) in the near future and that information can be conveyed to atrailing vehicle for use as appropriate by the platoon controller 110.Of course, there is a wide variety of other information that can be usedto foresee future torque or braking requests and that information can beconveyed in a variety of different forms. In some embodiments, thenature of the expected events themselves can be indicated (e.g., a hill,or curve or exit is approaching) together with the expected timing ofsuch events. In other embodiments, the intended future actions can bereported in the context of expected control commands such as theexpected torques and/or other control parameters and the timing at whichsuch changes are expected. Of course, there are a wide variety ofdifferent types of expected events that may be relevant to the platooncontrol.

The communications between the vehicles and the NOC may be transmittedover a variety of different networks, such as the cellular network,various Wi-Fi networks, satellite communications networks and/or any ofa variety of other networks as appropriate. The communications with theNOC may be coordinated by NOC communications controller 180. Theinformation transmitted to and/or received from the NOC may vary widelybased on the overall system design. In some circumstances, the NOC mayprovide specific control parameters such as a target gap tolerance.These control parameters or constraints may be based on factors known atthe NOC such as speed limits, the nature of the road/terrain (e.g.,hilly vs. flat, winding vs. straight, etc.) weather conditions, trafficor road conditions, etc. In other circumstances the NOC may provideinformation such information to the platoon controller. The NOC may alsoprovide information about the partner vehicle including itsconfiguration information and any known relevant information about itscurrent operational state such as weight, trailer length, etc.

The configuration file 190 may include a wide variety of informationabout the host vehicle that may be considered relevant to thecontroller. By way of example, some of the information might include thevehicle's specification including such things as engine performancecharacteristics, available sensors, the nature of its braking system,the location of its GNSS antenna relative to the front of the cab, gearratios, differential ratios etc.

FIG. 2 illustrates a particular embodiment of a platoon controller 110.In the illustrated embodiment, the platoon controller 110 includes a gapcontroller 112, a plurality of estimators 114, one or more trackers 116,any desired monitors 118 and potentially any of a variety of othercomponents 119.

In the illustrated embodiment, the gap controller 112 includes a targetand state setter 200, a gap regulator 210 and a gap estimator 240. Ingeneral, the target and state setter 200 is arranged to determine theintended operational mode (state) of the gap regulator 210 and thevalues of any variable control parameters that are appropriate for usein that operational mode.

The gap regulator 210 is arranged to control the trailing platoonpartner in the manner designated by the target and state setter 200. Inthe gap control operational mode, the gap regulator 210 controls thevehicle in a manner that seeks to attain and maintain the desired gap inaccordance with any designated control parameters specified by the statesetter 200. In other modes, the gap regulator 210 controls the vehiclein a manner that seeks to attain the appropriate response for theselected operational mode.

The gap estimator 240 is arranged to estimate/determine the current gapbased on actual measurements and/or other information that is availableto the platoon controller 110. It should be apparent that an accurateunderstanding of the current gap is important to successful operation ofthe gap regulator. At the same time, it should be appreciated that anymeasurement system has inherent tolerances and can be subject toreporting errors and/or may become unavailable in some circumstances.Thus, the gap estimator 240 is configured to receive information frommultiple position or relative position related sensors and to fuse suchdata into a reliable estimate of the current gap.

The torque and braking requests generated by GAP regulator 210 are sentto the appropriate actuator interface (e.g., engine torque interface 161and brake interface 162 respectively). The engine torque interface 161then forwards an appropriate torque command to engine torque controller152 which directs the delivery of the requested torque by directingvarious engine operating parameters such as fuel charge, valve timing,retarder state, etc. appropriately. The brake interface 162 generates anappropriate brake request that is sent to the brake controller 156.

A particular embodiment of gap controller 112 is described in moredetail below with reference to FIG. 3.

Returning to FIG. 2, there are a variety of estimators 114 that areuseful for the gap controller 112. In various embodiments these mayinclude one or more of a mass estimator 271, a drag estimator 273, aground speed estimator 275, a gyro bias estimator 277 and/or otherestimators 279.

The mass estimator 271 is arranged to estimate the respective masses ofthe platoon partners. These mass estimations may be used by the gapcontroller 112 to help scale its torque and brake requests appropriatelybased on the respective weights (masses) of the platoon partners.

The drag estimator 273 is arranged to estimate the respective dragresistances of the platoon partners. These drag resistance estimates mayalso be used by the gap controller to help adjust its torque and brakerequests appropriately. In general, the drag resistance of anyparticular truck or other vehicle can vary based on a variety of factorsincluding: (a) its drag profile (which in the context of a truck maychange based on the trailer being pulled—if any, or othercharacteristics of the load); (b) the vehicle's current speed, (c) windspeed and direction, (d) rolling resistance, (e) platoon state (e.g.,whether a platoon is active, the position of the vehicle within theplatoon, the gap), (f) bearing wear, etc.

The ground speed estimator 275 is arranged to estimate the actual groundspeed of the respective platoon partners. Many trucks and other vehicleshave wheel speed sensors that can quite accurately measure therotational speed of the associated wheels. The actual ground speed maydiffer from measured wheel speed based on the respective diameters ofthe wheels and slip conditions of the tires. The precise diameter of thewheels can vary based on the tires used. Furthermore, the diameter ofthe wheels will vary over time with tire wear, changes in ambienttemperature and other factors. The wheel diameter will even change overthe course of a particular trip as the tires heat up (or otherwisechange in temperature) during use. In practice, all of these variationsin wheel diameter are potentially significant enough to impact the gapestimation and gap control. Therefore, the ground speed estimator 275 isarranged to estimate the actual ground speed based on measured wheelspeed and other available information such as GNSS information. Theground speed estimates are particularly useful in times when trackerbased gap measurements (e.g., radar, cameras, LIDAR, etc.) aren'tavailable—which may occur, for example, when the platoon partners arelaterally offset due to a lane change, etc.

Several of the measurements utilized by the gap controller 112 areinertial measurements that are gyro based. These may include yawmeasurements which indicate the rate at which the associated vehicle isturning, longitudinal acceleration measurements, etc. Gyros often havean inherent measurement error referred to as a gyro bias that can affectmeasurements. The gyro bias estimator 277 estimates such biases to allowthe gap controller to compensate for such gyro based measurement errors.

The platoon controller 110 can include any other estimators 279 that maybe useful to any particular gap controller 112 as well.

The platoon controller 110 may also include one or more trackers 116.Each tracker 116 is arranged to measure or otherwise determine the gap.One type of tracker that is used in many implementations is a radarbased radar tracker 283. Newer commercially available trucks often comeequipped with a radar unit as standard equipment and radar trackers areparticularly well suited for use in such vehicles. Of course, one ormore radar units may be installed on any vehicle that does not comepre-equipped with a radar unit to facilitate use of radar tracker 283.By way of example, some specific radar trackers are described in moredetail in co-pending U.S. application Ser. Nos. 15/590,715 and15/590,803, both filed May 9, 2017, both of which are incorporatedherein by reference.

LIDAR is another distance measuring technology that is well suited formeasuring the gap between vehicles. LIDAR is quickly gaining popularityfor use in automated and autonomous driving applications. LIDAR tracker286 is well suited for use on vehicles that have or are provided withLIDAR units. Cameras and stereo cameras are also becoming more populardistance measuring tools for use in various automated and autonomousdriving applications.

Of course, other distance measuring technologies can be used to measureor estimate the gap between vehicles as represented by other trackers289. By way of example, a GPS tracker could be used that is basedprimarily on the respective reported GPS positions of the vehicles.

The tracker(s) used in many embodiments are configured to fuse data frommultiple sensors to help validate the measurements of the primarysensors used by the respective trackers. The aforementioned radartracker application describes a variety of methods for fusing data tohelp validate measurements of a primary sensor in that manner.

In various embodiments, the gap estimator 240 could replace or bereplaced by one or more of the trackers, or could be thought of as atracker itself since it determines/estimates the gap based on inputsfrom multiple sensors. In the illustrated embodiment, the gap estimator240 is shown separately as part of gap controller 112 since it fusesdistance data from the tracker(s) and any other available sources suchas GNSS sensors on each of the vehicles.

The platoon controller 110 may also include one or more monitors 118that are configured to monitor specific components that are relevant togap control. By way of example, one specific monitor that isparticularly useful to the control of platooning trucks is brake healthmonitor 291. The brake health monitor 291 is configured to monitor thebrake system and to identify circumstances in which the brakes may notbe able to deliver the level of braking normally expected for platooncontrol—as for example could occur if the foundation brakes include drumbrakes that have been used while traveling downhill in the mountains tothe extent that they are close to overheating. If the brake healthmonitor 291 identifies such a circumstance, it informs the platooncontroller, which can take the appropriate remedial action. Theappropriate remedial action will vary based on the specificcircumstances identified by the brake health monitor, but may include,for example, actions such as dissolving the platoon, increasing thetarget gap to a level more appropriate for the brake conditions, etc. Ofcourse, the brake health monitor can also configured to identifycircumstances in which the condition of the brakes has improved (e.g.,the brakes have cooled sufficiently) and inform the platoon controllerof those circumstances as well so that the platoon controller can actaccordingly. For example, improved braking status may allow the targetgap to be reduced, a platoon to be reestablished or other appropriateactions.

The platoon controller may include any of a variety of other monitors299 that are configured to monitor the state or status of othercomponents, systems, environmental conditions, road or trafficconditions, etc. that may be relevant to platoon control. For example, aDSRC link monitor may be provided to monitor the status of a DSRCcommunication link between the platoon partners.

Referring next to FIG. 3, another embodiment of gap controller 112 willbe described in more detail. Similarly to the embodiment illustrated inFIG. 2, the gap controller 112 includes a target and state setter 200, agap regulator 210 and a gap estimator 240. In the embodiment of FIG. 3,the target and state setter 200 includes an operating state selector203, and a control parameter selector 206 that determines, selects, setsor otherwise indicates to the gap regulator the values of any variablecontrol parameters that are appropriate for use in the selectedoperational mode.

The operating state selector 203 is arranged to determine the intendedoperational mode (state) of the gap regulator 210. In some specificembodiments, the operational modes might include a “normal” or “gapcontrol” operational mode in which the gap regulator is configured tocontrol towards attaining an maintaining a designated gap between thevehicles. In the gap control operational mode control parametervariables dictated by the control parameter selector might include thetarget gap itself (e.g. 10 m, 12 m, etc.)—which may vary somewhat basedon driving conditions (e.g., weather, terrain, road conditions, traffic,etc.). Other control parameters during normal operation may includeparameters that impact the draw-in speed, the tightness of the control,tolerances or variations between torque control and braking control,etc. In other embodiments, “initiate platoon” and/or “draw-in” or“pull-in” may be one or more separate states that are used to establisha platoon and/or to bring the platoon partners together in a safe mannerunder at least partially automated control.

Another potential operational mode is a “dissolve” mode in which theplatoon controller transitions the trailing vehicle toward/to a positionat which the driver of the trailing vehicle (or an automatic cruisecontrol system) can safely take over control of the vehicle. Generally,dissolving a platoon includes increasing the gap between the vehicles ina controlled manner to/towards a point at which the platoon can bedissolved and vehicle control can be safely transferred to manualcontrol by the driver or to control through the use of a differentsystem such as adaptive cruise control. The dissolve mode may optionallybe triggered by a wide variety of different circumstances, as forexample, in response to one of the platoon partners or the NOC decidingto terminate the platoon; the detection of a car cutting-in between theplatooning vehicles; the loss of communications between the vehicles foran extended period; the detection of an object in front of the leadvehicle that is too slow or too close to the platoon; etc.

Another potential operational mode may be a velocity control or relativevelocity control mode. Velocity control, or relative velocity controlmay be preferable to trying to control to maintain a particular gap in avariety of specific circumstances—as for example when the trailingvehicle's radar (or other) tracking unit loses sight of the partnervehicle, as can occur when there is a lateral offset between thevehicles due to a lane change or other conditions.

Of course, there can be a variety of other operational modes as well.

The gap regulator 210 is arranged to control the trailing platoonpartner in the manner designated by the target and state setter 200. Inthe embodiment illustrated in FIG. 3, the gap regulator 210 includes ascaler 212 and two separate controllers which are used in differentcombinations in different operating modes. In the illustratedembodiment, the controllers include a sliding mode controller 215 (whichperforms gap control) and a velocity/relative velocity controller 218.It should be appreciated that in other embodiments, a single controller,additional and/or different may be provided as appropriate for anyparticular implementation.

In the illustrated embodiment, the feed forward scaler 212 is configuredto scale the torque and brake signals from the front vehicle beforeadding them to the outputs from the sliding mode and relative velocitycontrollers 215, 218 to create the torque and brake request to theengine and brake controllers. Such scaling may be based on factors suchas the respective weights (masses) of the platoon partners, therespective drags of the vehicles, the severity of a braking event (e.g.,in high braking scenarios, the braking command may be increased a bit toprovide a margin of safety to account for uncertainties in brakingperformance and reactions times), etc. In other embodiments, suchscaling functions can be integrated into the respective controllersthemselves if desired.

The sliding mode controller 215 is configured to control the trailingvehicle in a manner that seeks to attain and maintain the desired gap inaccordance with the target gap and any other control parametersspecified by the control parameter selector 206. Thus, its primaryfunction is gap control. The velocity controller 218 is configured tocontrol the trailing vehicles in a manner that maintains a designatedvelocity relative to the lead vehicle, or in some circumstances, simplya designated velocity. In the illustrated embodiment, these two separatecontrollers are provided so that the gap regulator 210 can providedifferent types of control, as may be appropriate in differentoperational circumstances. A few specific examples are described withreference to FIGS. 4A-4C. In the described embodiments, both thecontrollers 215 and 218 are operated continuously during platooning andthe selector/adder 250 is used to select the appropriate signals tooutput based on the current operating mode. An optional braking monitor255 is a safety feature that may be utilized to help ensure that thebrake commands outputted by selector/adder 250 don't overly aggressivelybrake the trailing vehicle except in where necessary from a safety/crashprevention standpoint. This is to reduce the risk of traffic behind thetrailing platoon partner from being impacted by unexpected aggressivebraking of the trailing platoon partner.

The sliding mode controller 215 is arranged to control the trailingvehicle in a manner such that its relative velocity relative to thefront vehicle varies as a function of the gap between the vehicles. Thischaracteristic is illustrated in the state space diagrams of FIG. 5which show a control scheme in accordance with one specificimplementation. More specifically, FIG. 5 plots relative velocitybetween the vehicles (the Y-axis) vs. gap between the vehicles (theX-axis). FIG. 5 also show a torque request controller target controlline 320. In the illustrated embodiment, the nominal desired gap is 12meters—which is represented by line 310. Thus, the target control point311 is 12 meters with zero relative velocity, which is the pointrepresented by the intersection of line 310 (12 meters gap) and line 312(zero relative velocity).

The torque request controller component 221 of gap regulator 210 isconfigured to generate a torque request that is appropriate to controlthe gap in accordance with target control line 320. The torque requestis then implemented by engine torque controller 152. As can be seen inFIG. 5, when the gap is larger than the desired gap, the rear truck iscontrolled to travel slightly faster than the front truck is travelingsuch that the relative velocity of the rear truck has a small positivevalue. As the rear truck draws closer to the lead truck, its relativevelocity is reduced in a smooth manner until the gap is reduced to thetarget control point 311, at which point the relative velocity would bezero if perfect control were attained. If the rear truck gets closerthan the desired gap, it is slowed so that it has a negative relativevelocity relative to the lead truck to reestablish the desired gap.

The sliding mode controller 215 utilizes a unified sliding mode controlscheme during both the “pull-in” and gap maintenance stages ofplatooning. Configuring the sliding mode controller to control towardstarget control line 320 helps ensure that the relative speed vs. gaprelationship stays within a region safe for platooning.

In the embodiment illustrated in FIG. 3, the sliding mode controller 215includes separate controllers (e.g. torque request controller 221 andbrake request generator components 223) which are configured to controltowards different gap control targets. The different control targets areillustrated in the state space diagrams of FIG. 5 which show a controlscheme in accordance with one specific implementation. Morespecifically, FIG. 5 shows a brake request controller target controlline 330 in addition to torque request controller target control line320. FIG. 5 additionally shows representative transition paths fromvarious points in the state space to the torque request target controlline 320.

For most open highway driving conditions, modulating the torque requestalone is sufficient to control the gap appropriately without requiringthe use of the foundation brakes. This is in part because the torquerequest can be negative to a certain degree without needing to actuatethe foundation brakes through the use of engine braking and/or theretarder (if available). As mentioned above, when fuel is cut-off therewill be some pumping losses and some frictional losses in thepowertrain, so some level of negative torque can be provided while usingnormal valve timing by simply reducing the fuel charge appropriately.When larger negative torque is needed, the engine torque controller 152can create larger negative torques by actuating the retarder and/or bytaking other appropriate measures.

Separately, the brake request controller component 223 of gap regulator210 is arranged to generate brake requests during normal operation thatare generally arranged to maintain a different gap—specifically asmaller gap—than the torque request controller 221 targets. Thisdifference in the gaps that the torque and brake request controllerscontrol to is sometimes referred to herein as the gap tolerance 340. Ingeneral, brake requests 213 are not generated unless or until the gap isreduced at least the gap tolerance below the torque request targetcontrol line 320. Since the brakes can only be used to slow the vehicle,the effect of this difference is that the trailing truck will be allowedto creep in a relatively small amount (2 meters in the example) beforethe foundation brakes are actuated when the gap regulator 210 cannotmaintain the desired gap through control of the torque request alone.When the desired gap can be restored by modulating the torque requestsalone without crossing target brake control line 330, then thefoundation brakes do not need to be used at all. This has the effect ofsafely maintaining a gap while reducing the probability that thefoundation brakes will be deployed unnecessarily.

Normal gap control is illustrated in FIG. 4A. During normal gap control,the sliding mode controller 215 is use to determine torque and brakerequests that are appropriate to attain and maintain the target gap setby control parameter selector 206. When appropriate, the torque andbrake requests generated by the sliding mode controller 215 may bescaled appropriately by selector/adder 250 based on inputs from feedforward scaler 212. In this normal gap control mode, the outputs of therelative velocity controller 218 are not used in the control of thetrailing vehicle.

In some embodiments, the sliding mode controller 215 includes separatetorque request and brake request controllers 221, 223 as illustrated inFIG. 3. The torque request and brake request controllers 221, 223 areconfigured to control the engine and brakes respectively towardsdifferent gap targets which tends to provide a smoother, morecomfortable ride and reduce the use of wheel brakes (e.g., thefoundation brakes in tractor-trailer rigs) compared to control in whichthe engine and brakes are controlled to the same target gap. Such a gapcontrol architecture is described in more detail in U.S. Provisionalapplication No. 62/489,662, which is incorporated herein by reference.

Although the sliding mode controller 215 works very well to control thegap, there will be operational circumstances in which different types ofcontrol may be appropriate. For example, a different type of control maybe desirable when it is necessary to dissolve a platoon and return thetrailing vehicle to manual or other automated control. Typically, thegap between vehicles during platooning will be smaller, often muchsmaller, than can safely be maintained by a driver under manual control.Therefore, in general, when a platoon is dissolved with the intent torestoring manual control of the trailing vehicle, it will be desirableto grow the gap to a distance that is appropriate for manual controlbefore relinquishing control to the driver. This can be accomplished ina smooth manner by relative velocity controller 218.

When operating state selector 203 determines that the platoon should bedissolved, it directs the GAP regulator 210 to transition to a dissolvemode as represented by FIG. 4B. In the dissolve mode, primary control isprovided by relative velocity controller 218. The control parameterselector 206 may designate a desired (target) relative velocity for thetrailing truck during the dissolve. The specific target relativevelocity may vary based on the nature of the circumstances and/or thevehicles involved in the platoon. In general, it is desirable to selecta relative velocity that will cause the vehicles to gradually, butexpeditiously separate, without requiring the trailing vehicle to slowexcessively (which could unduly hinder following traffic) and preferablywithout requiring the lead vehicle to alter its drive plan. By way ofexample, relative velocities during dissolves on the order of 0.5 to 4meters per second, as for example, 1-2 m/s, have been found to work wellin the context of platooning trucks.

During a dissolve, the lead vehicle may take a variety of actions. Forexample, the lead truck may accelerate or increase its torque commandaggressively. In such cases, it may not be desirable to try toaccelerate the trailing truck in a similar manner thereby allowing thelead vehicle to pull away more than would otherwise occur under relativevelocity control. One way to accomplish this in the context ofplatooning trucks is to ignore or otherwise disable positive torquecommands from feed forward scaler 212.

Another potential scenario is that the lead truck brakes or slowssignificantly while under velocity control. In some circumstances, thevelocity controller 218 may be configured to permit a certain amount ofgap shrinkage when the gap is relatively larger to thereby reduce theoverall amount of braking required. In the illustrated embodiment, thesliding mode controller is configured to ensure that the gap between thevehicles is always sufficient to give the trailing vehicle sufficienttime to respond in a manner that prevents the trailing vehicle fromrunning into the back of the lead vehicle regardless of the occurrenceof (reasonable) unexpected events. Therefore, if the sliding modecontroller is outputting a braking or negative torque signal that has agreater magnitude than the relative velocity controller, then thatlarger braking/negative torque command should be passed to the vehicle'sengine and braking controllers. Therefore, during a dissolve, theselector/adder 250 is configured to only utilize negative commands(i.e., braking commands and negative torque commands) from the slidingmode controller 215 and to only use such commands when they are greaterin magnitude than the commands from the relative velocity controller218.

There may also be operational circumstances outside of dissolves inwhich relative velocity control or simply velocity control is desired.For example, there may be circumstances in which the back of the leadvehicle moves out of view of the trailing vehicle's tracker(s) 116 orthe tracker(s) 116 otherwise loses sight of the back of the platoonpartner. This can occur, for example, as a result of a lane change byone of the platoon partners. In such a circumstance the gap regulatormay not have an accurate measure of the longitudinal gap between thevehicles—and may have to rely on less accurate approaches fordetermining the gap such as the vehicle's respective GNSS positions. Insuch circumstances, it may be desirable to control the trailing vehicleto slowly drop back until the back of the lead vehicle comes within thetracker's view. Again, the relative velocity controller 218 is wellsuited for use in this circumstance—although the preferred relativevelocity control may be a bit different than occurs during a dissolve.Specifically, the goal is typically not to drop back as quickly or asfar as would occur during a dissolve—thus a smaller relative velocity(e.g. 0.5 m/s vs. 2 m/s), may be appropriate.

One approach to such relative velocity control is illustrated in FIG.4C. In the velocity control scheme of FIG. 4C velocity controller 218 isused in conjunction with normal scaling from feed forward scaler 212.This causes the trailing platoon partner to better follow lead vehicleaccelerations and/or torque increases than occurs during the dissolvestate illustrated in FIG. 4B. At the same time, for safety purposes,braking requests and negative torque request from the sliding modecontroller 215 may be utilized as appropriate by selector/adder 250 in amanner similar to the approach described above with respect to FIG. 4B.

Although particular platoon and gap controller architectures areillustrated in FIGS. 2 and 3, it should be appreciated that the specificarchitectures utilized may vary widely to meet the needs of anyparticular platooning or other automated vehicle control scheme.

As will be apparent to those familiar with the art, the describedcontrollers can be implemented algorithmically using software orfirmware algorithms executing on one or more processors, usingprogrammable logic, using digital or analog components or using anycombination of the preceding.

In the detailed description above, it is assumed that the controlledpower plant is an internal combustion engine, as for example a dieselengine. However, it should be appreciated that the described controlapproach can be utilized regardless of the nature of the power plantused to provide torque to drive the host vehicle. Thus, the describedcontroller design, functionalities and architectures may generally beapplied to the control of vehicles that utilize electric motors,turbines, fuel cells, or other types of powerplants to provide power toa drivetrain or directly to one or more wheels, including hybrids whichcombine more than one type of powerplant (e.g., hybrids that incorporateboth an electric motor and an internal combustion engine). When thepower plant is or includes an internal combustion engine, any type ofinternal combustion engine may be used including gas powered engines,diesel powered engines, two-stroke engines, 4-stroke engines, variablestroke engines, engines utilizing more than four-strokes, rotaryengines, turbine engines, etc.

The description above has focused primarily on tractor-trailer truckplatooning applications, however, it should be appreciated that thedescribed control approach are well suited for use in a wide variety ofconnected vehicle applications, regardless of whether one or more of thevehicles involved have 2, 3, 4, 18 or any other number of wheels, andregardless of nature of the powerplants used in such vehicle.

FIG. 6 illustrates a platoon control system hardware architecture thatis particularly well suited suitable for ASIL compliant platoon control.The illustrated embodiment includes three separate controller hardwareunits. These include platoon controller 410, vehicle interfacecontroller 460 and gateway processor 470. Selected components of arepresentative gateway processor 470 are illustrated in FIG. 7

As best seen in FIG. 6, the platoon controller 410 communicates with thevehicle interface controller 460 through an interface 420 and withgateway 470 through a direct link 478. In some embodiments, the link 478is a dedicated direct wired connection and no other devices are coupledto that link. The wired connection may be provided by any suitable formof cabling or traces, as for example co-ax cable, twisted pair wirings,fiber optics or any other suitable physical connection medium.

In the illustrated embodiment, the platoon controller 410 incorporatesall of the functionality of platoon controller 110 described above. Thevehicle interface controller 460 (also sometimes referred to as a systemmanager) performs the functionality of actuator interface 160 andfurther includes a number of safety monitors. In some embodiments, thesafety monitors are arranged to execute ASIL compliant safety monitoringalgorithms and the vehicle interface controller 460 is designed as anASIL compliant device.

In general, the vehicle interface controller 460 includes a highersafety level processor and software (including the safety monitors) thatindependently verifies the commands transmitted by the platooncontroller 110 before they are passed on to the vehicle actuators. Theseverifications use a subset of the available sensor inputs, together withverification algorithms that are independent and distinct from thoseused by the platoon controller.

The gateway processor 470 is arranged to coordinate communicationsbetween a host vehicle and the platoon partner(s) and to coordinatecommunication between the host and the Network Operations Center and/orany other entities that are external to the vehicle. As such, in aspecific implementation of the system illustrated in FIG. 1 the gatewayprocessor 470 includes the inter-vehicle communications controller 170and NOC communication controller 180 as best illustrated in FIG. 7.Typically the inter-vehicle communications controller utilizes ashort-range, vehicle-to-vehicle wireless communications protocol, as forexample the DSRC protocol. The NOC communication controller typicallycommunicates with a networks operations center using cellular orsatellite communications.

In some embodiments, the connection (link 478) between the gatewayprocessor 470 and the platoon controller 410 is a dedicated direct wiredconnection and no other devices are coupled to the link. In someimplementations an Ethernet or similar standardized wired communicationsprotocol is used to pass information between the gateway processor andthe platoon controller. This facilitates high speed, high reliabilitycommunications between the gateway processor and the platoon controller.In a specific example, a 100BASE or higher (e.g. 1000BASE, 10GBASE,etc.) Ethernet physical layer may be used, although it should beappreciated that a variety of other physical layers may be used in otherembodiments.

In some embodiments, the gateway processor 470 is also arranged tocommunicate with a forward facing camera 477 mounted on the vehicle anda dashboard display 475. When the host vehicle is the lead vehicle in aplatoon, the gateway processor transmits a video feed received from theforward facing camera 477 to the trailing vehicle(s) so that the driverof the trailing vehicle has a view of what is in front of the leadvehicle. When the host vehicle is a trailing vehicle in the platoon, thegateway processor 470 receives such a video feed from the gatewayprocessor on the lead vehicle and transmits the feed to the dashboarddisplay 475 where it is displayed to give the driver of the host vehiclea view of what is in front of the lead vehicle. Displaying a view ofwhat is in front of the lead vehicle to drivers of a trailing vehicle isdesirable to give the driver of the trailing vehicle a sense of comfort,better situational awareness and an ability to independently react tosituations that occur in front of the platoon. This can be particularlyimportant because in many platoons (e.g. platoons that involve tractortrailer trucks) the trailing vehicle will be very close to the leadvehicle (much closer than normal manual driving) and the lead vehiclewill effectively block the view of the trailing vehicle which can be anuncomfortable experience for drivers and/or passengers in a trailingplatoon partner—especially when they do not have access to a view ofwhat is going on in front of the platoon.

The video streams passed through the gateway may be managed by a videomanager 474. Since the gateway 470 communicates directly with the camera477 and/or dashboard display 475, the platoon controller 410 is not inany way burdened by the need to manage that data flow.

In some embodiments the gateway 470 also includes a message logger 473that logs various messages and other information passed there through inorder to provide a record for diagnostic purposes and the like. Thefunctionality of the message logger 473 will be described in more detailbelow.

The platoon controller 410 is configured as a listener on anyappropriate vehicle communications buses where it can directly obtaininformation about the vehicle's operational state—such as the vehicle'scurrent wheel speed, any brake or accelerator pedal inputs, steeringwheel position (as appropriate), transmission gear, etc. It is alsocoupled to sensor units such as GPS unit 131 to receive positionalinformation about the location of the vehicle, and to forward lookingradar unit 137 to receive information about the position of objectsoutside the vehicle (e.g., radar scenes). Similar information may beobtained from other sensors as well, such as LIDAR 138, camera(s) 139etc. Since the platoon controller 410 is configured strictly as alistener on the vehicle's communication bus(es) and does not itselftransmit information over such bus(es), it does not need to be ASILcompliant, as long as the control commands it outputs to the vehicleinterface controller are verified to ASIL standards by the vehicleinterface controller 460.

The vehicle interface controller 460 (also sometimes referred to as thesystem manager 460), which is ASIL compliant, is arranged to sendcommands to, and otherwise communicate with, the vehicle's enginecontroller (EECU), the brake controller (BECU), and/or any otherappropriate controllers either directly or via one or morecommunications buses, such as the vehicle's CAN bus(es).

In the illustrated embodiment, the interface 420 between platooncontroller 410 and vehicle interface controller 460 (also sometimesreferred to as the system manager 460) is fairly narrowly defined. Itincludes the substantive commands generated by the platooncontroller—which in the illustrated embodiment include torque request422, brake request 424, and optionally a retarder request 426. When theplatoon controller also controls the steering or other aspects of thehost vehicle steering and/or other appropriate control commands (notshown) may be included as well.

The interface 420 also includes a platooning state indicator 428 that isa signal from the platoon controller indicating whether or not itbelieves that its output should be directing operation of the vehicle.The platooning state indicator 428 may take many forms, as for example asimple flag that when high indicates that the platoon controller 410believes that platooning is/should be active and that its torque,braking and retard commands 422, 424, 426 should be followed. In such anarrangement, a low flag state indicates that the platoon controllerbelieves that it is not controlling the vehicle. The vehicle interfacecontroller 460 does not forward any torque, braking, retard or othercontrol commands at any time that the platooning state indicator 428indicates that platoon control is not active. In the event (generallyunlikely) that one of the safety monitors 465 indicates that platooningis not appropriate when the platoon controller 410 believes thatplatooning is valid (as indicated by platooning state indicator 428),the vehicle interface controller/system manager 460 initiates atermination of the platoon.

The interface 420 also facilitates the transmission of certain stateinformation—which is preferably ASIL validated state information—aboutboth the host vehicle and the partner truck that is useful to the safetymonitors. Specifically, the host vehicle state information 441 includesstate information about the host vehicle that has been validated (e.g.,ASIL-C validated) by the system manager 460 and is useful to one or moresafety monitors on the partner vehicle. The partner vehicle stateinformation 444 includes state information about the partner vehiclethat has been validated by the partner vehicle's system manager and isuseful for one or more safety monitors 465 on the host vehicle. Hostvehicle state information 441 is transmitted to the platoon controller410, which forwards such information without modification to the gateway470, which in turn forwards the host vehicle state information to thegateway on the partner vehicle. Partner vehicle state information 444received by gateway 470 from the partner vehicle's gateway is forwardedwithout modification to the platoon controller 410 and from there tosystem manager 460 (again without modification). Preferably the hoststate information 441 is transmitted with a checksum or other suitabledata integrity verification mechanism that allows the receiving systemmanager to verify that the data it receives is uncorrupted. Anycorrupted information can then be ignored. With this approach the ASILvalidated state information is passed without modification from one ASILcompliant device (system manager 460 on a first platoon partner) toanother (system manager 460 on a second platoon partner) and thereforeis suitable for use in ASIL compliant safety checking algorithms—evenwhen intermediate transmitting devices (e.g., platoon controller 410,gateway 470) are not themselves ASIL compliant.

The host and partner vehicle state information may include any ASILvalidated state information that is used by any of the safety monitors.This may include, for example, vehicle wheel speeds, brake requests,torque requests and/or delivered torque, brake air supply pressure,steering position, accelerometer readings and/or any other informationabout the partner vehicle used by the system manager 460 as part of asafety monitor. To the extent that the platoon controller 410 utilizespartner state information originated by an ASIL validated device beyondthe state information used by the system manager 460, that informationcan optionally be included in the vehicle state information 441, 444 aswell—although such inclusion is not necessary and usually not desirablesince such information can typically be obtained and sent by the partnervehicle's platoon controller, which reduces the bandwidth that needs tobe allocated to the interface 420.

It is noted that some of the host vehicle's sensor information (e.g.,wheel speed, brake pedal position, radar scenes, etc) is used by boththe platoon controller 410 and the system manager 460. Since the platooncontroller 410 is preferably an authorized listener on any appropriatevehicle control bus(es), the platoon controller does not need to wait toreceive such information from the system manager. Rather, it obtains anyrelevant host vehicle sensor information directly from the appropriatesensor over any suitable connection such as an appropriate CAN bus.However any sensor information relevant to the system manager on thepartner vehicle is read by the system manager (regardless of whether itis also read by the platoon controller) and included in host vehiclestate information 441 so that the partner vehicle's system manager isensured that such information is ASIL verified. In other embodiments anyhost vehicle sensor information that is not directly accessible by theplatoon controller can be received via the system manager 460 acting asan intermediary.

Although there will be some overlap in the sensor information used, itshould be appreciated that the host vehicle sensor information used bythe host vehicle platoon controller 410 and the host vehicle systemmanager 460 will often vary and may further vary from the partnervehicle sensor information of interest. For example, the host platooncontroller utilizes GNSS position data in the determination of thetorque and braking requests, however the GNSS position information maynot be utilized by the System Manager since it is not ASIL compliant.

Some of the sensor information that is used by the safety monitor on thehost vehicle may not be needed by the safety monitor on the partnervehicle. This may include information such as the radar scenes, theaccelerator pedal position, inputs from a host vehicle driver interfacedevice 469, etc. To the extent that such sensor information is not usedby the partner vehicle, there is no need for such information to beincluded in the vehicle state information 441, 444.

Some of a host vehicle's sensor information that is used by the platooncontroller on the partner vehicle may not be ASIL compliant andtherefore may not be used in the safety monitors on the partner vehicle.Such, sensor information that is not relevant to the safety monitors onthe partner vehicle does not need to be included as part of vehiclestate information 441, 444. Rather, such data may be obtained by theplatoon controller 410 and sent to the corresponding platoon controlleron the partner vehicle (by way of communication controllers 470). Forexample, it is extremely difficult to ASIL validate GPS or other GNSSposition data. Therefore, GNSS position data is preferably not includedin the vehicle state information 441, 444. Rather, such information ispassed from the host vehicle's platoon controller to the partnervehicle's platoon controller via the gateways 470.

The driver interface device 469 may be a button or other suitablemechanism positioned at a convenient location on the host vehicledashboard or elsewhere in the host vehicle cabin. The driver interfacedevice 469 is a mechanism that the driver may press as appropriate toindicate that the driver is ready to platoon during initiation of aplatoon, or to initiate the dissolution of a platoon when platooning isno longer desired. The use of the driver interface device 469 isdescribed in more detail in U.S. patent application Ser. No. 15/607,902which is incorporated herein by reference. In the illustratedembodiment, commands from the driver interface device 469 (which arepreferably ASIL compliant) are sent to the vehicle interface controller460 and passed from there to the platoon controller 410. Similarly,requests to the driver interface device pass from the platoon controllerto the vehicle interface controller 460 and from the vehicle interfacecontroller 460 to the driver interface device 469. This architecturesimplifies the work that must be done to make the driver interfacedevice 469 ASIL compliant. It should be appreciated, however, that inother embodiments, the platoon controller 410 may also be a directlistener to commands from the driver interface device. In the embodimentillustrated in FIG. 6, interface 420 includes driver platoon relatedrequests and commands 427 which represent the request sent to andcommands received from the driver interface device 469.

In some specific embodiments, the vehicle interface controller 460 isimplemented as a single dedicated integrated circuit chip and theplatoon controller 410 and gateway processor 470 are each implemented asseparate system on modules (SOMs).

The platoon control system hardware architecture illustrated in FIG. 6is particularly well suited for efficiently handling platooning controlrelated tasks in an ASIL compliant manner using information availablefrom a variety of sources including sources that are not themselvesASIL. With the described arrangement, the powertrain control commandsultimately issued by the control system may be ASIL rated.

The hardware architecture of FIG. 6 also has several advantages from asecurity standpoint. In the illustrated embodiment, the gatewayprocessor 470 is not connected to any of the vehicle's control relatedcommunications buses (e.g., the CAN bus(es)). Therefore, the gatewayprocessor 470, which is potentially the least secure of the threehardware components, is not able to transmit any information directlyonto any of the more secure vehicle communications buses or receive anyinformation directly from such buses—which is advantageous from asecurity standpoint since a nefarious entity cannot gain control thevehicle in any way by somehow hacking into the gateway processor 470.Furthermore, with this arrangement, the gateway processor 470 does notneed to be ASIL compliant which greatly simplifies its certification.

Applications for Using Mass Estimations for Vehicles

Estimating the mass of a vehicle can have a number of applications.

In one application, the mass of a vehicle can be used to control theoperation and system(s) on the vehicle itself (e.g., throttle, braking,steering, other actuators, etc.).

Vehicle mass estimations also have a number of applications in thecontext of platooning and related relative positioning of vehicles. Suchapplications may include organizing vehicles in general, arranging forvehicles to operate in a platoon using the relative estimated mass ofeach of the vehicles to select the lead and the following vehicles(s),scaling commands sent from the lead vehicle to the following vehicles(s)based on the relative mass of the vehicles operating in the platoon, andpossibly using the mass estimation of a vehicle to control operations onthe vehicle

In addition, mass estimations, or sensor data used to calculate massestimations, can be transmitted to a data processing center, such as aNetwork Operations Center (NOC), which may remotely coordinate theplatooning of vehicles. For instance, by coordinating a platoon andcommunicating the mass of the two (or more) vehicles prior toengagement, the vehicles can immediately assume their proper platoonposition (e.g., either the lead vehicle or following vehicle(s)) attheir point of contact. It should be noted that the terms dataprocessing center and NOC should each be widely construed to include awide variety of implementations. In some embodiments, the dataprocessing center and/or NOC may include one or more servers located ata single physical location. In other embodiments, the data processingcenter and/or NOC can be a distributed and include one or more serverslocated at different geographic locations, but interconnected over anetwork to share data and other communications.

FIG. 8 is a diagram showing how mass estimation of a vehicle istypically modeled. In this example, the forces acting on the vehiclewhile in motion are measured or modeled, such as rolling resistance(F_(rolling)), air resistance (F_(air)), the forces of gravity(F_(gravity)), particularly if the vehicle is travelling either up ordown hill, and any tractor forces (F_(tractive)) created by the vehiclepulling a tractor or other load. In addition, the acceleration of thevehicle is measured or modeled. Once the all the known forces aremeasured or modeled and the acceleration is modeled/known, mass iscalculated using algorithms based on Newton's second law(Force=Mass×Acceleration).

FIG. 9 is diagram illustrating how multiple mass estimation samplepoints are plotted over time to arrive at an accurate mass estimationfor a vehicle. For example, a mass estimation calculation may beperformed at fixed intervals of every 100 ms while the vehicle isoperating. As the different mass estimations data points are collected,they are plotted based on Force vs. Acceleration. After a sufficientnumber of samples, the data points typically converge, as represented bythe line 90 in the plot. Once this convergence takes place, a highlyaccurate estimation is realized, typically within five percent (5%) ofthe true mass of the vehicle.

The averaging of the mass estimation tends to result in a more accuratemass estimation in the presence in the presence of disturbances. Forinstance, a large tractor trailer may carry approximately 2000 lbs offuel with full tanks. As this fuel is consumed, the mass will driftdownward. By averaging over the duration of a trip, the mass estimationtracks changes in the mass due to fuel consumption.

FIG. 10 is a diagram 1000 illustrating various possibilities forestimating, reporting and/or using vehicle mass estimations inaccordance to different non-exclusive embodiments of the presentapplication.

In non-exclusive embodiments, sensors, such as sensors 130 (i.e., 131through 149) on tractor as illustrated in FIG. 1, generate sensor dataused to define the various measures of forces and acceleration used togenerate a mass estimation for a given vehicle. Such sensor data mayinclude, but is not limited to for example, engine torque, thetransmission gear ratio, wheel speed, retarder information, and/or GPSor other positioning and/or speed or acceleration information. Inaddition, the sensor data may also including braking events and brakingmagnitudes. However, as a general rule, sensor data collected during abraking event is not included in mass estimation samples. In general,braking events result in very large forces that are difficult toprecisely model. As a result, small errors in the braking model, whichare common, will typically introduce large errors in the modeled force,leading to large errors in the mass estimation calculation. Since it isdifficult to model the braking forces to a level of precision that wouldimprove the mass estimate (for example converting brake pressure tobrake force or deceleration), data collected during breaking events istypically not used during braking events. In yet other embodiments,other data may be bundled with the sensor data. Such other data mayinclude a vehicle ID, meta data, information contained in the vehicleconfiguration file 190. With a vehicle ID, the sensor data can be taggedto a particular vehicle. This feature is useful in situations where themass estimation for a vehicle is calculated at a location remote fromthe host vehicle that generated the sensor data, such as a dataprocessing center, such as a NOC, or on another vehicle.

The above represent a non-exhaustive list of sensor data that may beused for mass estimation calculations. It should be noted that othersensor data that may be considered may include data generated byactuator interfaces. For example, a sensor that measures the actualdelivered torque by an engine, not just the engine torque command, maybe used. In yet other embodiments, particularly with tractor-trailers,data generated by sensors that measure adjustable trailer axles, tirepressure, type and condition of the tires, the presence and/or positionof any aerodynamic aids (fixed or adjustable), the configuration of aparticular trailer or number of trailers, etc., may all be considered aswell.

In step 1002, the mass estimation calculation for a vehicle iscalculated and averaged over time, as discussed above. In oneembodiment, the “raw” sensor data for a vehicle is wirelesslytransmitted to a remote data processing center located on a network1006, such as a NOC. The mass estimation is then calculated by the dataprocessing center using the raw data. In an alternative embodiment, themass estimation calculation is performed on the host vehicle thatcollects the sensor data. In yet another embodiment, the sensor datacollected on a vehicle is transmitted to one or more other vehicles. Inresponse, the one or more other vehicles calculate the mass estimation.

In step 1004, the calculated mass estimation may be shared with a numberof different entities, depending on where the calculation was performed.For instance if a remote data processing center 1006, such as the NOC,performed the calculation, then the mass estimation may be reported toone or more other vehicles 1008 and/or the original or host vehicle 1010that generated the sensor data. Similarly, if the calculation isperformed by either the host vehicle 1010 or another vehicle (1008),then the calculation may optionally be reported to the center 1006, theone or more other vehicle 1008 and/or the host vehicle 1010.

The aforementioned embodiments provide just a few possibilities of wheresensor data generated on host vehicles may be transmitted to, where massestimation calculations may be performed, and the entities that receivethe mass estimate calculations. It should be understood that theseembodiments are merely illustrative and should be not be construed aslimiting. In actual embodiments, a wide variety of sensor data may betransmitted to one or multiple locations, the mass estimationcalculations for a vehicle may similarly be calculated at one ormultiple locations and may be shared with multiple entities, including aNOC, a data processing center, other vehicles and/or the host vehicle.The mass estimate calculations for vehicles may also be used in a numberof different ways, including but not limited to platooning.

FIG. 11 is a flow diagram 1100 showing steps for a Network OperationsCenter (NOC) using mass estimation data received from multiple vehicleto coordinate vehicle platooning.

In step 1102, sensor data is received at a NOC from a multiplicity ofvehicles as they each travel from location to location. While driving,each vehicle transmits its sensor data, at periodic intervals, typicallyover a wireless network using one of a number of wireless protocols suchas 3G, 4G, 5G, LTE, other cellular protocols known now or developed inthe future. WiFi, (Google's Remote Procedure Call (GRPC) protocol orjust about any other wireless communication protocol. For instance, avehicle may sample and send sensor data every 100 milliseconds.

In step 1104, the NOC calculates the mass estimates for each reportingvehicle as the sensor data is received. The NOC thus maintainsup-to-date mass estimation calculations for the multiple reportingvehicles as they drive from location to location.

In step 1106, the NOC identifies vehicles that are suitable forplatooning. A number of variables may be consideration when determiningif two (or more) vehicles should be paired and operate in a platoon. Forinstance, the type or class of the candidate vehicles, the vicinity ofthe candidate vehicles, the direction the candidate vehicles aretravelling, and other factors. For instance two tractor trailerstraveling in the same direction, along the same highway, and in the samegeneral vicinity, would typically make an ideal pair for platooning. Onthe other hand, the same two tractor trailers traveling in oppositedirections, on different highways, and many miles apart, are not goodcandidates for platooning.

In step 1108, once two or more vehicles for platooning are identified,the NOC determines the lead vehicle and following vehicles based on therelative mass estimations of each of the vehicles. As a general rule,the vehicle with the highest mass may be assigned the lead position. Forthe remainder of the vehicles, they are also ordered by mass behind thelead vehicle, from the largest to smallest in mass. Other ordering bymass may be chosen. For example in hilly terrain it may be moreimportant to order by power to weight ratio as opposed to mass.

In step 1110, the NOC notifies the vehicles and recommends that theyplatoon. The mass estimates and positions of each of the vehicles isalso reported to the vehicles joining the platoon.

In step 1112, the vehicles find one another on the road. With assistancefrom the NOC, the drivers of the two vehicles are directed to meet andengage in the platoon.

Finally, in step 1114, the vehicles assume their assigned position orderand initiate platooning at the point of contact. When more than twovehicles are in the platoon, there is no requirement that all thevehicles converge and begin platooning at a single location. On thecontrary, two vehicles can begin platooning at a first location and thenother vehicle(s) can join at subsequent location(s). As the additionalvehicles join, all the vehicles assume their assigned position in theplatoon as dictated by the relative mass estimations, for example, withthe vehicle with the largest mass leading to the vehicle with thesmallest mass at the back of the platoon (or otherwise based in part orentirely on the vehicle mass).

There are a number of reasons assigning the highest mass vehicle thelead position in the platoon, including:

(1) As a general rule, the larger the mass of a vehicle, the more likelythe vehicle will have diminished brake capabilities. For instance,larger mass vehicles have increased axle loading, experience more fade,require higher braking pressures and stress the braking system morecompared to a lower mass vehicle. As a result, heavier mass vehiclestypically have less predictable braking and will require a longerdistance to slow down and/or come to a stop during a braking event.Therefore, by placing the largest mass vehicle in the lead position, therisk of the lead vehicle being rear-ended by a following vehicle duringa breaking event is reduced.

(2) Larger mass vehicles, also as a general rule, have lowerpower-to-weight ratios, which makes them “slower”. Again, in the contextof platooning, it is typically beneficial to have a vehicle capable ofquicker acceleration in a following position. While vehicles areplatooning, it is often necessary for a following vehicle to accelerate,relative to the lead vehicle, to maintain a desired gap distance. If a“slower”, higher mass vehicle is in a following position, it makes itmore difficult for the following vehicle to speed up and maintain adesired gap.

While the largest mass vehicle is typically assigned the lead positionin a platoon, it should be understood that this is by no means arequirement. There are a number of reasons why a larger mass vehicle mayactually have better braking performance than a smaller mass vehicle.For instance, a smaller mass vehicle may have a poorly maintainedbraking system, worn tires capable of less grip, worn braking padsincapable of generating a high level of braking torque. For these andother reasons, it is possible for a heavier mass vehicle to actuallyhave better braking performance than a lower mass vehicle. Also, a lowermass vehicle may not always accelerate quicker than a heavier massvehicle. For instance with two tractor trailers, the power-to-weightratio of a vehicle carrying a high mass payload may actually be greaterthan another vehicle carrying a smaller mass payload if the latter has alarger engine with more horsepower than the former. For at least thesereasons, it may be preferred to place a smaller mass vehicle as the leadin a platoon. A NOC will therefore often consider a variety of factorsin deciding if a platoon of two or more vehicles is appropriate, and ifso, the proper order for organizing the vehicles in the platoon. Suchfactors may include, but are not limited to, the relative mass of thevehicles, the type or class of the vehicles, their relative brakingcapabilities, their relative power-to-weight ratios, their maintenancestatus, etc.

Once established, the relative mass estimations of the vehicles in theplatoon is useful for scaling commands generated by the lead vehicle.

FIG. 12 is a flow diagram 1200 showing steps how a following vehiclescales action commands received from a lead vehicle in a platoon basedon relative mass estimations between the two vehicles.

In step 1202, the lead vehicle generates and transmits an action commandto be taken by the lead vehicle to the following vehicle(s), either inthe form of an actuator signal or an acceleration, speed or positionprofile. For instance, the action can be either a throttle command or abraking command. In either case, the command will typically define acertain magnitude (i.e., an acceleration or a de-acceleration asmeasured in meters per second, an engine torque, a braking torque, brakepressure, etc).

In step 1204, the following vehicle(s) interpret the received commandand ascertains the action to be taken by the lead vehicle.

In step 1206, the following vehicle determines a scaling factor for thecommand based on the relative mass estimation of the lead and followingvehicles. In a non-exclusive embodiment, the scaling factor (“SF”) iscalculated from a product of a magnitude (M) of the command multipliedby a ratio defined by the mass estimation of the following vehicle(ME_(following)) divided by the mass estimation of the leading vehicle(ME_(leading)). In equation form, the SC is calculated by:

SF=M×(ME_(following)/ME_(leading))

It should be understood that the SC is not necessarily strictly based ona ratio of the mass estimations of the two vehicles. A host of otherfactors may also be considered, such as the type of vehicles involved,the number of trailer(s) pulled by either vehicle if any, themaintenance records, tire pressure and/or condition of both vehicles,types of engines, braking systems and/or transmissions in each vehicleas well as driving and/or road conditions. For example if the vehiclesare traveling down a large mountain pass as reported by a NOC, then thescaling of commands may be adjusted. Accordingly, it should beunderstood that the term scaling as used herein, should be widelyconstrued to mean both a strict ratio of the estimated masses betweenvehicles as well as the ratio being adjusted for a wide variety ofdifferent considerations.

In step 1208, the following vehicle implements the scaled action usingthe calculated scaling factor. For instance, if a lead truck with a highmass issues a braking command of high pressure applied, then a smallermass following vehicle can scale back the braking pressure application,knowing that it will take a lower braking pressure in the rear truck toachieve the same de-acceleration as the front truck. Similarly, with athrottle command, the rear vehicle will scale back its throttle responsesince it accelerates at a faster rate with the same torque applicationcompared to the higher mass lead vehicle. In either case, gap controlbetween the two vehicle is enhanced since the following vehicle canscale its accelerations and/or de-accelerations relative to the highermass lead vehicle.

As an illustrative example, consider two trucks with the front truck at80,000 lbs (such as a fully loaded 53 foot trailer behind a tractor) andthe following truck at 40,000 lbs (such as near empty trailer plustractor). While cruising, the front truck might be putting out 25% moretorque to overcome rolling resistance (which is greater with greatermass) and wind resistance (which doesn't increase with added mass).During cruising the system in the rear truck may use this knowledge todetermine a starting point for torque to apply (before closing the loopusing control around gap), for example the front truck might be applying1000 N-m and the rear truck is applying 800 N-m. When a hill begins, thefront truck may need an additional 500 N-m. The rear truck candetermine, for example, that based on the mass estimate, it needs onlyabout an additional 250 N-m.

FIG. 13 is a diagram 1300 listing how a vehicle may use an estimation ofits mass to control the operation of and systems on a vehicle. Forinstance, the mass estimation of a vehicle, regardless if calculated onthe vehicle itself or received wirelessly from a data processing centersuch as a NOC, can be used to control or influence operations on thevehicle itself. Such operations may include path planning (e.g., brakingor swerving/steering), vehicle control (e.g., determining a steeringangle, a braking force for a given de-acceleration, or the magnitude ofa torque demand) and/or the control of certain on-board actuators toimplement the above (e.g., steering torque, brake pressure, throttle,etc.). One situation where a mass estimation of a vehicle may bebeneficial is with path planning. The mass is important because it isone of the primary determining factors around what trajectories arefeasible for the vehicles. For instance, consider a situation where atractor-trailer encounters an obstacle on the road ahead, such as astalled car. The preemptive action to take to avoid a collision may varydepending on the mass of the tractor trailer. If the trailer is loadedwith heavy cargo (e.g. a high mass), then a sudden swerve may bedangerous, possibly causing the trailer to tip over or to not besuccessful in following the desired trajectory. Thus, the mass estimateis needed in these cases to determine what path the vehicle shouldattempt to follow. For example, under such a scenario, braking may be apreferred action rather than swerving. This determination can becommunicated to the driver, or alternatively with autonomous orsemi-autonomous vehicles, the braking action is implemented instead ofsteering.

Mass estimation may also be intelligently used for control of varioussystems and actuators on a vehicle.

With braking events for instance, the magnitude of a braking force, andconsequently the amount brake pressure generated by braking actuators,can be scaled according to the mass of a vehicle. If a tractor-trailerwishes to brake at a rate of (−0.2 meters per second), then the amountof braking force and pressure generated by the braking system can scaleddepending on the mass of the tractor-trailer. With high mass, thebraking force and pressure are adjusted upward, whereas both can bescaled down with a low mass vehicle. This determination may also bebased on other factors, such as the braking system hardware andsoftware. For example a vehicle with larger brake chambers or more brakechambers may provide more deceleration from the same brake pressure.

Acceleration events can also be similarly scaled at least partiallybased on mass. More engine torque is typically required for a high masscompared to a low mass tractor trailer for a given acceleration (e.g.,+0.3 meters per second). In addition to this simple scaling, thecontroller response may also be adjusted based on mass, to account forthe difference in speed of response of the vehicle to the torqueapplication. Steering actuation may also be based on mass. This can becritical in the steering position control loop (where the goal is asteering angle and the choice is how much steering torque to apply) orin the choice of a steering angle to meet a desired trajectory. For theformer, the steering torque depends directly on weight on the axle, aswell as on force created from the dynamics of the vehicle proportionalto the vehicle mass. For the steering angle, the trajectory a vehiclewill follow given a speed and steering angle, depends on the mass of thevehicle.

The examples provided above are merely illustrative and should not beconstrued as limiting. In actual embodiments, just about any system oractuator on a vehicle can be controlled, wholly or partially, based onthe mass estimate of a vehicle. Such systems may include, but are notlimited to, a fuel injection system, a knock control system, asuspension control system, an engine controller system, an autonomous orsemi-autonomous driving control system, a cruise control system and/oran automatic transmission control system.

FIG. 14 is a diagram that illustrates a data processing pipeline 1400used for determining a mass estimation for a vehicle with a resetfunction. As previously discussed, the mass of a vehicle is calculatedby modeling the forces acting on the vehicle, measuring the accelerationof the vehicle, calculating for mass using Newton's second law, and thenaveraging a multitude of mass estimation samples over time.

In this non-exclusive embodiment, the data pipeline 1400 includes a baddata mask 1402, a Finite Impulse Response (FIR) filter 1404, a vehiclemodel module 1406 and an averaging module 1408.

As previously described, the pipeline 1400 receives the sensor data froma vehicle, which may include data indicative of engine torque,transmission gear ratios, GPS or positioning information, wheel speedand/or braking events.

The bad data mask 1402 acts to filter or remove data that is considered“bad” or inaccurate, meaning sensor data collected while the vehicle istraveling over a particularly bumpy/rough road, data collected while thevehicle is traveling at a very slow rate of speed (e.g., 9 mph or less)or GPS information collected while the vehicle is traveling under abridge or through a tunnel, etc.

Once the bad data is removed, the remaining data is filtered by FIRfilter 1404, which may apply in a non-exclusive embodiment, a 0.5 HzLow-Pass cutoff frequency to the data. The advantage of applying the FIRfiltering is that it removes phase lag from the sensed data and providesa well defined “wind up” time.

The filtered sensed data is then applied to the vehicle model module1406. Within module 1406, certain sensor data is masked or rejected. Forexample, sense data collected during braking events and possibly a shorttime thereafter (e.g., 5 seconds) is removes since it is typicallydifficult to model braking forces. In addition, data collected duringsteady state engine torque and/or high gear ratios may also be maskedsince it is often difficult to model the forces acting on the vehicle inthese states as well. Once certain data is masked, the module 1406creates a force model for the given vehicle. In general, the force modelrelies a number of model parameters (e.g., wheel diameter, engine andretarder efficiency, engine inertia, an aerodynamic drag coefficient,etc.). From these parameters, the total force action on the vehicle(F_(total)) can be modeled using the following:

F _(total) =m×a _(total), where:  (1)

F _(total) =F _(engine) −F _(aero) _(_) _(drag) −F _(rolling) _(_)_(resistance); and  (2)

a _(total) =a _(measured)+gravity×sin(grade)  (3)

By periodically sampling the sensed data and running it through themodule 1406, a plurality of mass estimate (m) sample values aregenerated, which are then averaged by the averaging module 1408. Forexample, a large number of samples may be generated over a period oftime and plotted. When the samples “converge”, an accurate estimation ofthe mass of the vehicle is realized.

For more details on the pipeline 1400, see the above mentionedpublications by Holm and Bae, Rye and Gerdes, both incorporated byreference herein.

It should be noted that the pipeline 1400 described above is merelyexemplary and other mass estimation algorithms may be used, eithercurrently known or developed in the future. With this in mind, theparticular pipeline described and illustrated herein should not beconstrued as limiting in any manner.

Regardless of the mass estimation algorithm or data pipeline used, theApplicant is not aware of any example that relies on a reset function,such as that implemented by the reset module 1410 provided in thepipeline 1400. As detailed below, the reset module 1410 may be used toreset the pipeline and begin fresh mass estimations with fresh sensordata when certain reset conditions occur, as described in the twoembodiments below.

In a non-exclusive embodiment, two mass estimation pipeline calculationsare run in parallel. The first or primary is a “long horizon” massestimation pipeline calculation, while the second or secondary is a“short horizon” mass estimation pipeline calculation.

The first or primary calculation is conducted indefinitely, provided thevehicle is operating and is in motion. The first or primary calculationis stopped only when the vehicle has stopped moving for more than athreshold period of time (e.g., 1, 5 minutes, etc.). If such a stopoccurs, it is possible that the mass may change significantly after thevehicle resumes driving. For instance during a stop, a truck may deliverits cargo, or change trailers, both of which may result in a drasticchange in mass. To take this possibility into account, the primarycalculation discards the already collected sensor data and restarts themass estimation calculation with fresh data collected after drivingresumes.

On the other hand, the second or secondary mass estimation calculationoperates only over short intervals of time (e.g., 2, 5 minutes, etc.).After the time interval expires, the previously collected sensor data isdiscarded and the second mass estimation calculation is reset usingfreshly sensed data, providing the vehicle is still operating and isdriving. Since the second or secondary calculation is performed over ashort time horizon, it typically (although not necessarily) will be lessaccurate and stable compared to the first or primary calculation,however, the secondary calculation will be indicative of how the massmay have changed from one time interval to the next. In variousembodiments, the intervals are fixed, meaning the reset of the secondmass estimation calculation occurs when each fixed interval expires. Onalternative embodiments, the short intervals may vary or range betweenseveral reset time intervals.

Comparing the primary and the secondary mass estimations, running inparallel, provides a useful “sanity check”. If the difference betweenthe two is less than a threshold, such as 10% to 15%, it is a strongindicator that the mass of the vehicle has not drastically changed andthe primary calculation is accurate. On the other hand if the thresholdis exceeded, it sets a flag that the mass of the vehicle may havesignificantly changed. As a result, the mass estimation calculation isconsidered compromised and the first or primary pipeline 1400 is resetby the reset module 1410.

FIG. 15 illustrates a flow chart 1500 of steps for executing primary andsecondary mass estimation calculations with the reset function 1408.

In the initial step 1502, it is determined if the vehicle is in motion.

When the vehicle is in motion, the primary and secondary massestimations are initiated in parallel in steps 1504 and 1508respectively.

In step 1506, the primary mass estimation calculation is performedindefinitely, provided the vehicle has not stopped for more than athreshold period of time.

The primary mass estimation calculation is reset by module 1410 in step1507 if the vehicle comes to a stop for more than the threshold periodof time.

When the vehicle resumes motion, as determined in step 1502, the primarymass estimation calculation will resume in step 1504.

In parallel, the secondary mass estimation calculation is performed instep 1508.

In decision 1510, it is determined if the short time horizon hasexpired. If yes, the reset module resets the secondary mass calculationin step 1511.

If the vehicle remains in motion following a reset, steps 1508, 1510 and1511 are continually repeated

As a result, the primary and secondary calculations are continuallygenerating mass estimations while the vehicle is in motion.

In step 1512, the primary and secondary mass estimation calculations arecontinually compared. If the difference is less than the threshold(e.g., 10% to 15%), the above process is continually repeated.

On the other hand of the difference is larger than the threshold, thenthe primary mass estimation is flagged as compromised. If the designatedthreshold is exceeded, then it is assumed something has occurred tocompromise the primary mass estimation. As a result, the primary massestimation is reset in step 1507 and the process begins with fresh data.

If the vehicle is operating in a platoon, any number of actions may betaken when the mass estimation calculation is deemed compromised. Forinstance, the platoon can be dissolved or the gap can be widened as asafety precaution. If/when the primary and secondary mass estimationsonce again are within the threshold as determined in step 1512, then theplatoon can be resumed and/or the gap reduced.

In yet other embodiments, the reset function implemented by module 1410can be used in other settings that may not be suitable for platooning.Several examples are described below.

With tractor trailers, drastic mass changes can occur in a short periodof time. For instance, a tractor may load or unload the cargo in itstrailer or switch trailers in a short period of time. The trailer may beeither significantly heavier or lighter after the change.

Certain vehicles, such as a gravel truck, may dump its cargo (e.g.,gravel) out of the back while moving at a slow speed.

The mass of a vehicle may also drastically change, depending on itslocation. A cement truck will have its mass drastically increase at theconcrete yard when picking up a new load of concrete, while the masswill significantly drop at a construction site when the concrete ispoured.

In each of the above scenarios, the mass of the vehicle drasticallychanged. Using the result module 1410 in each of these instances,meaning based on time, speed or location, resets the mass estimatecalculation using fresh sensor data, while discarding stale data thatmay no longer be accurate.

FIG. 16 illustrates a flow diagram 1600 for resetting a mass estimationfor a vehicle optionally based on of vehicle stops, speed, location orany combination thereof.

In the initial step 1602, it is determined if the vehicle is in motion.

In step 1604, the mass estimation calculation is initiated when thevehicle is in motion.

In steps 1606 it is determined if a reset condition has been met or not.If not, the above process is repeated, provided the vehicle is inmotion. If yes, the reset module 1410 resets the mass calculationestimation in step 1608.

When a reset occurs as provided in step 1608, the step of performing themass estimation calculation is stopped until the reset condition is nolonger met. When the reset condition is no longer present, theabove-described process repeats starting at step 1602. The re-startingof the mass estimation calculation can be either a pause or are-setting. In the case of the former, at least some of the existingdata used for the calculation prior to the stop is used once thecalculation resumes. On the other hand with a re-setting, all the priordata is discarded and the calculation begins anew with data collectedafter the stoppage.

As previously noted, the reset condition may be based on time, speed orlocation, or any combination thereof. For instance, in accordance withdifferent embodiments, the reset may be implemented only when any one,two or all three conditions are met.

Therefore, the present embodiments should be considered illustrative andnot restrictive and the invention is not to be limited to the detailsgiven herein, but may be modified within the scope and equivalents ofthe appended claims.

What is claimed is:
 1. A method, comprising: generating sensor data fora first vehicle; detecting when a braking event occurs on the firstvehicle; calculating a mass estimation for the first vehicle based onthe generated sensor data, wherein the generated sensor data generatedduring the braking event is excluded from the calculation; and sharingthe calculated mass estimation for the first vehicle with one or moreadditional vehicle(s).
 2. The method of claim 1, wherein the calculationof the mass estimation for the first vehicle includes a primarycalculation and a secondary calculation.
 3. The method of claim 2,wherein the primary calculation is conducted indefinitely while thevehicle is operating and is in motion.
 4. The method of claim 3, whereinthe secondary calculation operates over intervals of time.
 5. The methodof claim 4, wherein the generated sensor data used to calculate thesecondary calculation is discarded and the secondary calculation isreset.
 6. The method of claim 1, wherein the generated sensor data usedfor calculating the mass estimation for the first vehicle includes onefrom the group consisting of: (a) engine torque; (b) transmission gearratios; (c) GPS or positioning information; (d) wheel speed; (e) actualdelivered engine torque; (f) tire pressure; (g) tire condition; (h)presence or position of aerodynamic aids (i) configuration of anytrailers; (j) a number of trailers; and/or (k) one or more traileraxles.
 6. The method of claim 1, wherein the braking event consists ofan activation of a retarder.
 7. The method of claim 1, wherein thebraking event consists of an activation of a regenerative brakes.
 8. Asystem comprising: a sensor configured to generate sensor data for afirst vehicle, wherein the sensor is configured to detect when a brakingevent occurs on the first vehicle; an electronic device configured tocalculate a mass estimation for the first vehicle based on the generatedsensor data, wherein the sensor data generated during the braking eventis excluded from the calculation; and sharing the calculated massestimation for the first vehicle with one or more additional vehicle(s).9. The system of claim 8, wherein the calculation of the mass estimationfor the first vehicle includes a primary calculation and a secondarycalculation.
 10. The system of claim 9, wherein the primary calculationis conducted indefinitely while the vehicle is operating and is inmotion
 11. The system of claim 10, wherein the secondary calculationoperates over intervals of time.
 12. The system of claim 11, wherein thegenerated sensor data used to calculate the secondary calculation isdiscarded and the secondary calculation is reset.
 13. The method ofclaim 8, wherein the braking event consists of an activation of aregenerative brakes.
 14. The method of claim 8, wherein the brakingevent consists of an activation of a retarder.
 15. The method of claim8, wherein information associated with a braking event excluded from thecalculation is transmitted wirelessly to another vehicle.
 16. A method,comprising: generating sensor data for a first vehicle; attempting tocalculate a mass of the first vehicle based on the generated sensordata; in response to detecting a force applied to the first vehicle thatmay introduce errors in the calculation of the mass of the firstvehicle, excluding sensor data generated during the application of theforce from the calculation of the mass of the first vehicle.
 17. Themethod of claim 16, wherein the calculation of the mass estimation ofthe first vehicle includes a primary calculation and a secondarycalculation
 18. The method of claim 17, wherein the primary calculationis conducted indefinitely while the vehicle is operating and is inmotion.
 19. The method of claim 18, wherein the secondary calculationoperates over intervals of time.
 20. The method of claim 17, wherein thegenerated sensor data used to calculate the secondary calculation isdiscarded and the secondary calculation is reset.